The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A user authentication process is normally used in networks that carry data, voice or other information to determine whether a user or client seeking to access a network actually is who the user purports to be. Numerous message protocols have been developed to specify how to perform authentication with network devices such as switches, routers, gateways, and gatekeepers. Typically, an authentication protocol requires a client to prove its identity by offering a data credential that is verified in a secure manner by an authentication server. Some such servers also perform network access control and accounting functions and therefore are termed authentication, access and accounting (AAA) servers. A commercial example is CiscoSecure Access Control Server, from Cisco Systems, Inc.
The emergence of numerous diverse authentication protocols spurred a movement toward developing a generalized authentication protocol that could be extended to support various platforms and purposes. Extensible Authentication Protocol (EAP), as described in IETF RFC 2284, is becoming the preferred user authentication protocol for most types of network sessions across different network devices. In large part, this popularity stems from the extensible nature of EAP, which allows any device that provides generic support for the protocol to transparently support new authentication protocols, known as EAP methods.
Although EAP provides flexibility to choose a different authentication type or EAP method for any single authentication, the protocol inherently limits each authentication to use a single method for each individual authentication request. Each authentication transaction under EAP is effectively atomic, and the outcome of each transaction may be one of only two states, namely success or failure.
As defined in RFC 2284, each EAP message includes a “Type” field, which indicates the EAP method being used for the authentication of the session. The Type field is required regardless of which encapsulation type is used to transport the EAP message, such as Remote Authentication Dial In User Service (RADIUS), which is defined in IETF RFC 2138; point-to-point protocol (PPP), as defined in RFC 1661; EAPOL, etc. As stated in RFC 2284, “Normally, the Type field of a Response message is the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports.” The RFC can be interpreted as if EAP prohibits changing the EAP method during an authentication session. As a result, network elements cannot run multiple authentication methods sequentially or in parallel.
When EAP was designed, this limitation was not problematic, because the authentication protocols it replaced had the same limitation.
As the requirements for network usage become more sophisticated and security of sessions become more critical, a protocol that provides only a binary result, success or failure, from a single authentication method, seriously limits the treatment that the network may apply to each request.
One approach to this problem is to abandon or modify the EAP protocol and replace it with a new protocol that does not suffer from the deficiency described above. However, this approach would require a significant investment in modifying or installing updated EAP supplicants (clients), EAP authenticators (network devices) and AAA servers, also requiring significant third party co-operation. Therefore, it is desirable to adopt an approach that utilizes the existing EAP infrastructure without modification.
Based on the foregoing, there is a clear need for an approach for performing multiple authentication methods within an authentication protocol that provides for a single authentication type. There is a need for a mechanism that provides for the use of an arbitrary number of authentication methods or types for each individual authentication request.
It would be useful to have such a mechanism that is compatible with existing protocol infrastructure in general, and compatible with unmodified EAP in particular.